在說完迭代，
很多人都會想到敏捷開發，
這也是很多人所認識的開發方法論，
當然所謂的迭代不代表是敏捷開發，
而只是其中的一個核心。

而往往很多公司都會訴說著，
採用敏捷開發，
那麼首先要先來了解敏捷開發是什麼？

基本理念:
敏捷開發的基本理念是建立一個靈活、自我組織、能夠快速適應變化的團隊。它強調與客戶的緊密合作、小型迭代和需求的不斷調整。

工作範圍:
敏捷開發通常更關注整個開發過程的靈活性，包括需求的變化和持續的客戶參與。

開發節奏:
敏捷開發的迭代週期可以較短，通常持續2至4週。這樣的短週期有助於快速反應需求變化。

客戶參與:
敏捷開發強調客戶或代表的積極參與，客戶通常參與到每個迭代中，提供反饋並協助優先事項的確定。

需求變化:
敏捷開發視需求變化為正常現象，鼓勵在開發過程中進行變更，以確保產品符合客戶需求。

可以看到，
字裡行間都寫滿著彈性，
幾乎可以說與瀑布模式的穩定背道而馳，
並且不只是作業上的彈性，
還包含客戶也不斷在各個流程可以提供意見，
並且對於意見是非常包納的。

而要達成這個條件，
首先是要有極高的配合團隊，
其次才會是其他事務。

對於筆者而言，
會對敏捷開發下一個結論，
協作、快速交流與保持討論。

我很喜歡前輩所寫的這句話，
團隊是否已經有心理準備不再有標準答案？是否已經具有不斷調整的覺悟？

但這句話不是代表可以隨意更改的，
而敏捷開發中有個重要觀念，
開發節奏(sprint)與task(需求)
在一個開發節奏(sprint)決定好的task(需求)是不能變的，
就算是有著需求，
盡可能的都會在下個sprint排進去，
而不會是任何需求都簡單的可以在任何時候更改。

當然事情總有例外，
但例外之所以是例外，
就是正常來說不會遇到，
真的遇到再接化發就行。

不會是因為很敏捷就可以隨便塞，
隨便改，並且還很快，
任何修改都會是需要時間的，
這只是一個方法論。

許許多多公司都極力推崇敏捷開發，
甚至以此為傲想拿來吸引人，
但敏捷開發是一種開發方法，
而不是一種萬靈丹。

重於人，互助保持討論，
不論哪種開發法，
保持這種基底都是好的，
沒有所謂的用這種就很好，
有許多種不同的開發方法，
隨時可能出現新的開發模式以應對不斷變化的時代需求，

對於開發方法論，
筆者抱持著記得主流方法，
依照現行狀況進行一定調整。

就如同瀑布開發，
常常會被人覺得不好，
但也常常許多地方採用，
不論是明確的小型專案，或是在磨合團隊等等，
在眾多狀況下還是會用這個方式。

各種開發法這個定義出來的目的，
就是為了讓開發更為簡單、明確、容易配合，
所以只要能達成這個目的，
任何的開發法都是可以去使用的，
沒有萬用的方法論，只有合適的方法論。

------------延伸閱讀
軟體開發模型
https://medium.com/@ArthurKC/%E8%BB%9F%E9%AB%94%E9%96%8B%E7%99%BC%E6%A8%A1%E5%9E%8B-ba9e49bef880

筆者在這邊說一下，
在寫完後看這篇文章，
原來筆者的認知確實有著相當程度的重合。

筆者當初在學完敏捷開發，
在當下就認為是以人為核心圍繞而出的開發方法論。
而這位前輩描述的也更好，除此之外還圖文並茂。

敏捷開發本質是一個–參與者為中心。每一位參與者在團隊中都共享同一個目標

各位如果對軟體開發模型有興趣，看完筆者粗淺的介紹還想更深入，挺推薦這位前輩所寫的文章。